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Abstract 

We  present  a  methodology  to  facilitate  the  design 
and  analysis  of  secure  cryptographic  protocols.  We 
advocate  the  general  approach,  and  a  new  avenue  for 
research,  of  restricting  protocol  designs  to  well-defined 
practices,  instead  of  ever  increasing  the  complexity  of 
protocol  security  analysis  mechanisms  to  deal  with  ev¬ 
ery  newly  discovered  attack  and  the  endless  variations 
in  protocol  construction.  In  particular,  we  propose  a 
novel  notion  of  a  fail-stop  protocol,  which  automati¬ 
cally  halts  in  response  to  any  active  attack  that  inter¬ 
feres  with  protocol  execution,  thus  reducing  protocol  se¬ 
curity  analysis  to  that  of  passive  attacks  only.  We  sug¬ 
gest  types  of  protocols  that  are  fail-stop,  outline  some 
proof  technigues  for  them,  and  use  examples  to  illus¬ 
trate  how  the  notion  of  a  fail-stop  protocol  can  make 
protocol  design  easier  and  can  provide  a  more  solid 
basis  for  some  available  protocol  analysis  methods. 

1  Background  and  Motivation 

In  a  distributed  system,  security  depends  heavily 
on  the  use  of  secure  protocols  such  as  authentication 
protocols  (e.g.,  [22,  25])  and  secure  communication 
protocols  (e.g.,  [4]).  It  is  well  known  that  such  pro¬ 
tocols  can  fail  even  if  the  underlying  cryptosystems 
are  sound  and  can  have  very  subtle  security  flaws  that 
are  quite  difficult  to  debug  [6].  In  fact,  the  proto¬ 
col  security  problem  is  undecidable  in  that,  given  any 
protocol  analyzer,  there  are  protocols  whose  security 
the  analyzer  cannot  decide.  We  can  reduce  this  prob¬ 
lem  to  the  Turing  machine  halting  problem  by  simply 
defining  a  protocol  that  broadcasts  all  its  secrets  if  the 
analyzer  finds  it  secure  and  does  nothing  otherwise. 

Recent  years  have  seen  notable  efforts  devoted  to 
developing  methods  -  theories,  logics,  formal  meth¬ 
ods,  and  tools  -  to  facilitate  the  analysis  of  the  security 
of  cryptographic  protocols  (e.g.,  [9,  6,  19]).  Although 
these  results  are  significant,  they  also  have  limitations. 
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Automated  and  semi-automated  methods  based  on  al¬ 
gebra  and  state  transitions  model  protocols  at  a  fairly 
detailed  level  [19].  This  can  make  them  difficult  to 
apply  and  their  application  computationally  intensive 
and  intensive  in  human  labor.  Some  of  these  methods 
are  designed  for  searching  out  vulnerabilities  rather 
than  proving  protocols  secure.  The  failure  to  find  a 
vulnerability  by  such  a  method  does  not  mean  that 
the  protocol  is  secure,  but  merely  that  certain  lines  of 
attack  are  less  likely  to  succeed. 

Methods  based  on  modal  logic  [6,  2],  on  the  other 
hand,  seem  more  conclusive  in  that  their  aim  is  to  pro¬ 
duce  a  proof  of  protocol  security  by  deducing  that  cer¬ 
tain  protocol  goals  are  achieved.  However,  such  meth¬ 
ods  generally  make  a  number  of  assumptions,  some 
of  which  cannot  be  justified  by  the  methods  them¬ 
selves.  Most  of  these,  such  as  the  assumption  that 
one  can  identify  one’s  own  messages  or  that  one  can 
distinguish  between  a  random  string  and  a  properly 
encrypted  message,  can  be  guaranteed  by  additional 
constraints  on  protocol  specification  or  implementa¬ 
tion.  They  can  also  be  dealt  with  by  logics  with  more 
complicated  constructs  (e.g.,  [14]). 

The  single  most  difficult  assumption  is  that  a  secret 
remains  secret  during  an  execution  of  the  protocol.1 
When  Nessett  raised  the  difficulty  with  this  assump¬ 
tion  of  secrecy  [24],  no  satisfactory  answer  could  be 
provided,  although  it  is  probably  unfair  to  say  that 
the  logic  of  Burrows,  Abadi,  and  Needham  (the  BAN 
logic)  is  flawed  because  the  logic’s  scope  is  explicitly 
defined  not  to  handle  the  issue  of  secrecy  [7].  Never¬ 
theless,  this  secrecy  assumption  is  paradoxical  in  that 
whether  a  secret  can  remain  secret  may  depend  cru¬ 
cially  on  whether  the  protocol  is  secure.  Thus  the  as¬ 
sumption  cannot  be  used  to  derive  the  security  of  the 
protocol  unless  a  separate  mechanism  can  justify  this 
assumption.  None  of  the  later  published  extensions  of 
this  logic  resolves  this  difficulty.  Some  of  these  logics 
have  a  model-theoretic  semantics  [2,  33,  34]  and  can  be 

1  Abadi  and  Tuttle  [2]  in  their  new  semantics  of  the  logic 
of  Burrows,  Abadi,  and  Needham  [6]  relaxed  this  assumption 
by  assuming  instead  that  a  secret  can  be  leaked  but  whoever 
possesses  it  (maybe  illegally)  will  not  misuse  it.  This  is  logically 
sound  even  though  it  does  not  reflect  what  usually  happens  in 
the  real  world. 
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used  to  directly  examine  the  truth  of  such  assumptions 
[32,  33].  However,  such  analysis  is  not  formal,  and  to 
guarantee  that  it  is  comprehensive  would  seem  to  in¬ 
volve  methods  as  intensive  as  those  mentioned  above 
[19].  An  earlier  work  by  Dolev  and  Yao  [9]  proved 
that  protocols  using  public-key  cryptosystems  [8]  and 
having  certain  very  rigid  structures  can  automatically 
satisfy  the  secrecy  assumption.  However,  the  restric¬ 
tions  on  the  protocols  are  so  strict  -  for  instance,  one 
can  only  append  to  a  message  -  that  the  results  are 
not  widely  applicable. 

Given  the  above  observations,  we  propose  a  new  ap¬ 
proach  to  designing  secure  protocols  that  is  centered 
on  a  novel  notion  of  fail-stop  protocols.  This  notion 
is  partly  inspired  by  the  work  on  fail-stop  processors 
by  Schlichting  and  Schneider  [27].  They  proposed  the 
concept  of  a  fail-stop  processor,  which,  when  failing, 
stops  completely  before  any  effect  is  visible  to  the  out¬ 
side  world.  Schneider  also  showed  how  to  construct 
a  fail-stop  processor  using  Byzantine  agreement  [28]. 
A  desirable  result  of  this  fail-stop  behavior  is  that 
it  is  much  easier  to  reason  about  fault-tolerant  sys¬ 
tems  built  with  fail-stop  processors,  compared  with 
processors  that  may  have  omission  or  Byzantine  fail¬ 
ures.  Just  as  the  notion  of  fail-stop  processors  helped 
to  simplify  the  design  and  analysis  of  fault-tolerant 
systems,  we  show  that  the  notion  of  fail-stop  proto¬ 
cols  helps  to  simplify  the  design  and  analysis  of  secure 
protocols. 

A  fail-stop  protocol  automatically  halts  when  there 
is  any  derivation  from  the  designed  protocol  execu¬ 
tion  path.  Consequently,  the  only  difference  between 
effects  of  passive  attacks  and  active  attacks  is  that  the 
latter  can  cause  early  termination  of  a  protocol  exe¬ 
cution.  Thus,  we  need  to  analyze  only  the  effect  of 
passive  attacks,  and  in  particular,  it  is  now  much  eas¬ 
ier  to  conclude  whether  the  secrecy  assumption  can 
be  violated.  One  obvious  benefit  is  that  once  we  show 
that  the  secrecy  assumption  for  a  protocol  holds,  a 
logical  analysis  using  the  BAN  method  and  its  varia¬ 
tions  (usually  referred  to  as  BAN-like  logics)  will  be 
much  more  convincing. 

From  another  angle,  just  as  algorithms  or  programs 
should  be  designed  for  their  correctness  to  be  easily 
proven  [17,  26],  security  protocols  should  be  designed 
so  that  their  security  can  be  proven  with  relative  ease. 
The  difficulties  encountered  by  previous  efforts  of  pro¬ 
tocol  analysis,  in  our  view,  can  be  to  some  extent  at¬ 
tributed  to  the  undisciplined  ways  in  which  a  protocol 
can  be  designed  (and  then  submitted  for  analysis).  By 
imposing  a  few  restrictions  on  the  format  the  messages 
of  a  protocol  can  take,  we  can  greatly  reduce  the  types 


of  protocols  we  have  to  deal  with.  The  specific  con¬ 
struction  of  fail-stop  protocols  presented  in  this  paper 
can  result  in  practical  and  usable  protocols,  and  there¬ 
fore  the  restrictions  are  not  as  limiting  as  one  might 
have  first  thought. 

To  summarize,  the  advantage  of  our  new  approach 
can  be  seen  in  the  following  light.  Most  current  re¬ 
search  in  cryptographic  protocol  analysis  is  focused 
on  extending  and  enhancing  the  existing  methods  in 
order  to  analyze  ever  more  complicated  features  and 
unexpected  attacks.  However,  the  logical  methods  are 
generally  easy  to  apply  but  rely  on  assumptions  that 
are  hard  to  justify,  while  search-based  methods  are 
difficult  and  computationally  intensive.  Therefore,  we 
advocate  an  alternative  approach  where  protocol  de¬ 
signs  should  be  made  more  restricted,  disciplined,  and 
well  structured.  We  expect  that  such  well-designed 
protocols  can  be  analyzed  by  existing  (or  even  sim¬ 
pler)  methods  and  hope  that  this  approach  opens  a 
new  avenue  for  research. 

As  a  starting  point  within  this  general  approach, 
we  propose  a  novel  notion  of  fail-stop  protocols,  which 
has  the  advantage  of  excluding  the  feasibility  of  active 
attacks  so  that  protocol  analysis  can  focus  on  the  re¬ 
maining  case  -  namely,  passive  attacks  that  may  lead 
to  information  leakage  -  and  provide  a  more  solid  ba¬ 
sis  and  some  simplifications  for  proofs  of  security.  We 
note  that  the  analogy  with  fail-stop  processors  [27]  is 
more  in  spirit  than  in  practice.  For  example,  in  fault 
tolerance,  it  has  been  relatively  successful  to  classify 
faults  into  a  handful  of  ordered  (in  terms  of  difficulty) 
categories.  These  faults  are  generally  well  understood 
and  there  are  well-defined  methods  to  protect  against 
them.  In  computer  security,  however,  and  in  proto¬ 
col  security  in  particular,  characterizing  all  types  of 
threats  completely  and  usefully  is  non-trivial.  This  is 
because  new  types  of  attacks  are  still  being  discovered, 
the  relationships  between  attacks  and  the  combined 
effects  of  them  are  unclear,  and  there  is  no  consensus 
that  all  known  classes  of  attacks  have  satisfactory  so¬ 
lutions.  Therefore,  when  a  protocol  is  claimed  to  be 
secure,  the  claim  is  implicitly  against  an  assumed  set 
of  threats  and  is  often  dependent  on  implicit  assump¬ 
tions  about  the  nature  of  protocols  or  messages  that 
may  be  violated  in  the  presence  of  an  unforeseen  type 
of  attack  [18]. 

In  the  rest  of  this  paper,  we  first  define  (albeit  in¬ 
formally)  fail-stop  protocols.  Then,  we  discuss  how  to 
analyze  the  security  of  such  protocols.  After  that,  we 
describe  how  to  construct  practical  fail-stop  protocols. 
Finally,  we  discuss  some  extensions  and  directions  for 
future  work. 
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2  Fail-Stop  Protocols  and  Analysis 

We  model  a  distributed  system  as  a  collection  of 
processes  which  are  spatially  separated.  They  com¬ 
municate  with  each  other  by  exchanging  messages.  A 
protocol  is  a  specification  for  the  format  and  relative 
timing  of  the  messages  exchanged.  A  cryptographic 
protocol  uses  cryptographic  mechanisms  such  as  en¬ 
cryption  and  decryption  algorithms  to  guarantee  the 
integrity,  the  secrecy,  the  origin,  the  destination,  the 
order,  the  timeliness,  and  ultimately  the  meaning  of 
the  messages.  We  assume  that  a  protocol  executes  in 
steps  or  rounds. 

Using  Lamport’s  definition  of  causality  [20],  we  can 
organize  the  messages  of  a  protocol  into  an  acyclic  di¬ 
rected  graph  where  each  arc  represents  a  message  and 
each  directed  path  represents  a  sequence  of  messages. 
In  a  fail-stop  protocol,  if  a  message  actually  sent  is  in 
any  way  inconsistent  with  the  protocol  specification, 
then  all  those  messages  that  are  behind  this  altered 
message  on  some  path  in  the  graph  (i.e. ,  they  are 
causally  after  the  altered  message)  will  not  be  sent. 
We  must  assume  that  the  attacking  party  does  not 
possess  the  encryption  key  with  which  the  target  mes¬ 
sage  is  encrypted;  otherwise,  a  forgery  may  not  be 
detectable. 

Definition  1  (Fail-Stop  Protocol)  A  protocol  is 
fail-stop  if  any  attack  interfering  with  a  message  sent 
in  one  step  will  cause  all  causally -after  messages  in 
the  next  step  or  later  not  to  be  sent. 

We  sometimes  also  conveniently  call  such  a  message 
fail-stop.  Note  that  the  definition  is  stated  in  a  rather 
informal  language.  This  is  intentional  so  that  the  basic 
idea  and  the  intuition  can  be  more  easily  presented.  It 
should  not  be  a  difficult  matter  to  formalize  the  idea 
once  it  is  accepted  as  appealing  and  useful. 

Before  describing  and  justifying  the  following  claim, 
we  must  first  limit  what  we  mean  by  an  active  attack. 
These  are  attacks  that  involve  the  capturing  and/or 
inserting  of  messages  (including  plaintext,  whole  en¬ 
crypted,  signed,  and  pieces  of  messages).  Specifically, 
we  assume  that  message  integrity  is  protected  within 
an  encryption,  signature,  or  some  other  mechanism. 
Thus,  for  example,  attacks  utilizing  both  the  protocol 
structure  and  the  cryptographic  algorithm  to  allow 
message  splicing,  and  integrity  attacks  based  on  the 
mode  of  DES  operations  in  encrypting  certain  proto¬ 
col  messages,  are  assumed  to  have  been  independently 
addressed  [30,  31]. 

Claim  1  Active  attacks  cannot  cause  the  release  of 
secrets  within  the  run  of  a  fail-stop  protocol. 


Claim  1  then  follows  immediately  from  the  defini¬ 
tion  of  a  fail-stop  protocol,  because  active  attacks  do 
not  cause  more  (or  different)  messages  to  be  sent;  so 
an  attacker  using  active  attacks  cannot  obtain  more 
secrets  than  one  using  passive  eavesdropping.  More 
generally,  since  an  active  attack  will  cause  a  fail-stop 
protocol  to  halt,  in  a  fail-stop  protocol  no  principal 
will  ever  produce  encryptions  or  any  other  computa¬ 
tions  on  data  from  a  message  that  was  not  entirely 
legitimate.  Therefore,  we  need  to  consider  only  pas¬ 
sive  attacks  in  which  an  adversary  records  messages 
and  tries  to  compute  secrets  from  them.  Such  passive 
attacks  (and  protection  measures  against  them)  are 
much  better  understood  than  active  attacks,  and  we 
come  back  to  this  subject  in  the  next  section. 

Note  that  a  legitimate  principal  might  mount  an 
attack  using  a  protocol  to  cause  another  to  generate 
ciphertext  based  on  known,  chosen,  or  recognizable 
plaintext.  For  example,  in  a  three  party  protocol,  the 
attacker  could  cause  an  indefinite  number  of  cipher- 
texts  to  be  sent  from  one  of  the  other  parties  to  the 
third  by  legitimately  initiating  the  protocol.  These 
texts  might  then  be  useful  for  breaking  a  key  based 
on  ciphertext-plaintext  pairs.  Fail-stop  protocols  by 
themselves  prevent  only  the  generation  of  messages 
due  to  deviations  from  a  protocol’s  intended  execu¬ 
tion.  They  cannot  prevent  attacks  based  on  proper  ex¬ 
ecutions  of  the  protocol.  We  assume  that  other  mech¬ 
anisms  have  been  employed  to  prevent  these  attacks 
and/or  that  they  have  been  independently  shown  to 
be  of  no  use. 

Given  Claim  1  and  its  implications,  we  suggest  the 
following  proof  methodology  for  a  fail-stop  protocol, 
as  shown  in  Table  1.  This  particular  methodology 
aims  to  put  model-logic  based  methods  on  a  stronger 
footing  in  the  sense  that  we  have  removed  the  paradox¬ 
ical  secrecy  assumption  in  BAN-like  logics  by  indepen¬ 
dently  validating  it.  Other  proof  methodologies  may 
become  available  later,  and  they  may  aspire  to  prov¬ 
ing  different  or  additional  kinds  of  security  properties 
that  are  deemed  important  in  cryptographic  protocol 
analysis  and  verification. 


Phase  1.  Verify  that  the  protocol  is  fail-stop. 
Phase  2.  Validate  the  secrecy  assumption. 

Phase  3.  Apply  BAN-like  logics. 

Table  1:  A  proof  methodology  for  fail-stop  protocols 

In  the  following  sections,  we  discuss  these  three 
phases  of  protocol  analysis  in  more  detail.  Checking 
the  validity  of  the  secrecy  assumption  sometimes  can 
be  used  to  disprove  the  security  of  a  protocol  by  show- 
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ing  that  the  assumption  does  not  hold.  This  usage  is 
independent  from  the  other  two  phases.  Also,  even 
for  fail-stop  protocols  that  sustain  the  secrecy  assump¬ 
tion,  the  application  of  BAN-like  logics  is  still  useful 
in  finding  protocol  design  errors.  We  will  give  an  ex¬ 
ample  to  demonstrate  this  presently,  after  Claim  2. 

2.1  Practical  Fail-Stop  Protocols 

One  way  to  verify  that  a  protocol  is  fail-stop  is  to 
show  that  the  protocol  conforms  to  one  of  the  known 
specifications  of  fail-stop  protocols.  To  build  up  such  a 
“library”  of  protocol  specifications,  we  first  give  one  of 
the  simplest  specifications  of  fail-stop  protocols.  For 
simplicity,  we  assume  for  the  moment  that  only  sym¬ 
metric  key  cryptosystems  (such  as  DES)  are  used,  and 
every  pair  of  communicating  processes  share  a  secret 
encryption  key. 

Claim  2  A  protocol  is  fail-stop  if: 

1.  The  content  of  each  message  has  a  header  con¬ 
taining  the  identity  of  its  sender,  the  identity  of 
its  intended  recipient,  the  protocol  identifier  and 
its  version  number,  a  message  seguence  number, 
and  a  freshness  identifier. 

2.  Each  message  is  encrypted  under  the  key  shared 
between  its  sender  and  intended  recipient. 

3.  An  honest  process  follows  the  protocol  and  ignores 
all  unexpected  messages. 

4-  A  process  halts  any  protocol  run  m  which  an  ex¬ 
pected  message  does  not  arrive  within  a  specified 
timeout  period. 

Here  a  freshness  identifier  can  be  a  timestamp  (if 
clocks  are  assumed  to  be  securely  and  reliably  syn¬ 
chronized)  or  a  nonce  issued  by  the  intended  recipi¬ 
ent.  When  a  freshness  identifier  takes  on  a  more  com¬ 
plicated  form,  the  rules  for  reasoning  about  freshness 
[6,  14]  can  be  used  to  determine  if  the  identifier  is  fresh 
with  regard  to  the  recipient.  Basically,  if  x  is  deemed 
fresh  and  y  cannot  be  computed  (in  a  computationally 
feasible  way)  by  someone  without  the  knowledge  of  x, 
then  y  is  also  deemed  fresh  [14].  Note  that  a  proto¬ 
col  consisting  of  two  or  more  messages  based  entirely 
on  nonces  cannot  be  fail-stop  because  the  first  mes¬ 
sage  cannot  be  fresh.  We  can  extend  the  concept  of 
fail-stop  protocols  to  fail-safe  protocols  to  better  treat 
nonce-based  protocols,  as  we  discuss  in  Section  4. 

To  see  that  Claim  2  is  valid,  we  note  that  a  mes¬ 
sage’s  header  uniquely  identifies  the  position  of  the 
message  (e.g.,  within  which  protocol  execution  and 


which  message  of  this  execution).  It  is  not  possible  to 
use  this  message  elsewhere  without  modifying  the  mes¬ 
sage.  However,  since  the  message  is  encrypted  with 
the  key  shared  between  its  sender  and  recipient,  no 
one  else  can  make  undetectable  modifications  without 
obtaining  the  key  first.  In  particular,  it  is  possible 
to  guarantee  that,  by  proper  encoding  of  the  header 
information  under  the  encryption  algorithm,  the  mes¬ 
sage  header  provides  sufficient  redundancy  so  that  any 
random  modification  of  the  message  can  be  detected 
with  an  extremely  high  probability.  We  assume  that 
this  correct  encoding  can  and  will  be  independently 
verified.  Recently,  Abadi  and  Needham  collected  a 
number  of  prudent  engineering  principles  for  designing 
authentication  protocols  [1],  The  above  specification 
of  fail-stop  protocols  satisfies  some  of  these  principles. 
Requirements  of  robustness  and  explicitness  [3]  are  re¬ 
lated  to  similar  ideas. 

We  now  give  an  example  protocol  that  satisfies 
Claim  2  and  is  thus  fail-stop.  Nonetheless,  it  still  has 
design  flaws  that  can  be  revealed  by  a  BAN-like  logic. 
As  typical  in  the  literature,  we  use  A  —>■  B  :  x  to  de¬ 
note  that  A  sends  message  x  to  B,  (x,y)  to  denote 
concatenation  of  x  and  y,  {*}*,  to  denote  encryption 
of  x  with  key  k,  and  {*})[  to  denote  decryption2  of  x 
with  key  k. 

In  the  following  protocol  as  shown  in  Table  2,  server 
S  distributes  a  session  key  k  to  be  shared  between 
clients  A  and  B.  Each  message  includes  the  iden¬ 
tities  for  the  message  sender,  the  recipient,  a  times¬ 
tamp,  a  protocol  identifier  and  its  version  number,  P , 
a  message  sequence  number,  and  session  key  k,  and 
is  encrypted  with  the  key  already  shared  between  the 
server  and  the  recipient. 


1.  S^A:  {S,A,T„P,N,k,B}ka. 

2.  S^B:  {S,B,T„P,N+l,k}kb' 

Table  2:  BAN-like  logics  useful  for  fail-stop  protocols 

This  protocol  clearly  satisfies  Claim  2  for  processes 
that  satisfy  clauses  3  and  4  therein.  (Note  that  process 
behavior  pertaining  to  clauses  3  and  4  cannot  be  spec¬ 
ified  in  this  type  of  protocol  description,  which  is  why 
we  assume  them  separately.)  The  protocol  is  thus  fail- 
stop.  However,  the  second  message  differs  from  the 
first  in  that  the  session  key  is  not  clearly  associated 
with  the  identity  of  another  party,  thus  B  after  re¬ 
ceiving  message  2  will  not  know  with  whom  he  shares 

2  We  are  assuming  the  use  of  a  public  key  system  in  which 
decryption  and  signing  amount  to  the  same  operation,  e.g., 
RSA.  Other  systems  might  require  these  to  be  notationally 
distinguished. 
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the  key  k.  Such  design  errors,  which  can  have  serious 
security  implications,  have  been  found  elsewhere  by 
using  BAN-like  logics  [14]. 

Fail-stop  protocols  using  public-key  systems  can  be 
similarly  formulated.  The  only  difference  is  in  the  en¬ 
cryption  of  the  message. 

2.  Each  message  is  signed  by  ihe  sender’s 
private  key.  The  message  can  then  be  op¬ 
tionally  encrypted  under  the  public  key  of  the 
recipient. 

Here  we  assume  that  the  sender’s  private  key  and  the 
recipient’s  public  key  do  not  cancel  each  other  and 
thus  reveal  plaintext.  In  the  case  that  the  sender  and 
the  recipient  are  the  same  party,  we  assume  that  the 
message  is  sent  via  its  local  circuit  and  is  not  revealed 
to  the  outside.  The  order  of  signing  and  encrypting 
can  be  reversed  in  some  situations,  but  in  all  cases, 
it  is  prudent  not  to  encrypt  or  sign  purely  random 
messages.  We  will  come  back  to  this  point  later. 

Also,  it  is  not  difficult  to  combine  the  above  two 
formulations  for  fail-stop  protocols  using  both  types 
of  cryptosystems,  but  we  do  not  further  discuss  this. 
When  one  can  assume  that  encryption  is  sufficient 
proof  of  the  sender’s  identity  (e.g.,  when  the  encryp¬ 
tion  key  uniquely  identifies  the  sender),  we  can  relax 
the  requirement  that  the  sender  identification  be  in¬ 
cluded  in  the  message  plaintext.  Checking  if  a  protocol 
conforms  to  Claim  2  (thus  being  fail-stop)  is  easy. 

Many  published  protocols  are  not  fail-stop  as  we 
defined.  One  reason  is  that  many  designers  try  to  be 
economical  -  they  would  want  to  send  plaintext  mes¬ 
sages  whenever  they  think  it  safe  to  do  so.  However, 
this  kind  of  unguided  (and  rather  ad  hoc)  “optimiza¬ 
tion”  is  easily  one  of  the  rich  sources  of  security  bugs. 
As  the  late  Christopher  Strachey  once  remarked  (re¬ 
told  by  Roger  Needham  in  his  invited  talk  at  ACM 
CCS-1,  November  1993),  one  cannot  foresee  the  con¬ 
sequences  of  being  too  clever.  Nevertheless,  examples 
have  shown  that  guided  optimizations  can  indeed  iden¬ 
tify  and  remove  redundant  data  from  messages  [5]. 

Moreover,  sometimes  auxiliary  data  are  sent  in  the 
clear.  For  example,  the  identity  of  the  sender  of  an  en¬ 
crypted  message  is  sent  along  when  it  helps  the  recipi¬ 
ent  to  choose  the  correct  key  for  decryption.  The  pres¬ 
ence  of  such  data  does  not  change  the  nature  of  a  pro¬ 
tocol  being  fail-stop.  For  example,  if  the  sender  iden¬ 
tification  is  modified,  then  the  recipient  will  choose  an 
incorrect  key  and  fail  to  decrypt  the  message.  This 
modification  will  thus  cause  the  recipient  to  halt,  so 
the  protocol  is  still  fail-stop. 


2.2  Validating  the  Secrecy  Assumption 

In  BAN-like  logics,  a  secrecy  assumption  is  that  a 
data  item  is  known  only  to  a  set  of  parties.  Since  active 
attacks  simply  halt  the  execution  of  a  fail-stop  proto¬ 
col,  an  attacker  is  better  off  waiting  for  the  protocol  to 
complete  and  gathering  as  many  messages  as  possible 
(to  use  for  deducing  secrets).  Therefore,  to  check  that 
no  other  party  can  obtain  the  item  through  attacks, 
given  that  one  can  record  all  messages  exchanged  dur¬ 
ing  a  protocol  execution,  our  task  is  to  determine 
whether  any  party  can  learn  a  particular  data  item  by 
manipulating  the  messages  (together  with  those  data 
items  the  party  already  has  in  possession). 

This  question  is  related  to  that  of  the  “state  of 
knowledge”  [21]  in  that  we  need  to  find  out  what  infor¬ 
mation  an  attacker  has  gathered  by  recording  the  exe¬ 
cution  of  a  protocol.3  The  notion  and  rules  of  “posses¬ 
sion”  proposed  by  Gong,  Needham,  and  Yahalom  (the 
GNY  logic  [14])  can  be  applied  directly  for  this  pur¬ 
pose.  Briefly,  given  a  set  of  formulas  (or  data  items) 
that  an  attacker  is  thought  to  possess  (through  record¬ 
ing  or  other  means),  possession  rules  can  be  used  to 
derive  all  formulas  the  attacker  can  possess.  Suppose 
a  formula  can  be  the  concatenation  of  sub-formulas. 
For  example,  message  hello,  I  am  alive  consists  of  sub¬ 
formulas  hello  and  I  am  alive.  The  possession  rules  can 
be  summarized  as  the  following: 

•  possession  of  a  formula  implies  possession  of  every 
sub-formulas  contained  in  the  formula. 

•  possession  of  all  sub-formulas  contained  in  a  for¬ 
mula  implies  possession  of  the  formula. 

•  possession  of  a  data  item  implies  possession  of  a 
function  of  the  data  where  the  function  is  compu¬ 
tationally  feasible  to  compute. 

•  possession  of  a  formula  and  an  encryption  implies 
the  possession  of  the  formula  encrypted  with  the 
key. 

•  possession  of  an  encrypted  formula  and  the  ap¬ 
propriate  encryption  key  implies  the  possession 
of  the  formula  after  decryption. 

We  later  see  how  these  rules  can  be  applied  to  real 
examples.  We  simply  note  here  that  although  it  seems 
that  these  rules  can  be  applied  indefinitely  to  add  new 
formulas  to  an  attacker’s  possession,  in  practice  there 

3  We  can  use  the  same  method  to  check  how  much  infor- 
mation  can  be  gathered  by  recording  multiple  executions  of  a 
protocol  or  of  a  number  of  protocols.  We  do  not  further  discuss 
this  issue  here. 
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are  suitable  guidelines  as  to  when  to  terminate  inves¬ 
tigating  if  a  particular  secret  can  be  in  the  attacker’s 
possession.  For  example,  if  all  relevant  formulas  have 
at  most  2  levels  of  nested  encryption,  then  it  is  futile 
to  try  to  encrypt  beyond  two  levels.  Also,  if  all  for¬ 
mulas  exchanged  in  the  protocol  are  either  plaintext 
or  encrypted,  then  it  is  useless  to  apply  decryption  to 
plaintext  formulas. 

2.3  Applying  BAN-like  Logics 

The  last  phase  in  the  suggested  proof  methodology 
of  fail-stop  protocols  is  to  apply  the  BAN-like  logics. 
As  we  have  shown  in  the  beginning  of  this  section, 
fail-stop  protocol  can  still  have  subtle  errors  that  can 
be  captured  using  BAN-like  logics. 

It  is  important  to  note  that  a  fail-stop  protocol 
of  the  form  defined  in  Claim  2  automatically  satis¬ 
fies  most  of  the  assumptions  necessary  to  apply  the 
BAN  logic.  For  example,  the  sender  information  en¬ 
sures  that  one  can  identify  one’s  own  messages.  Also, 
there  is  sufficient  redundancy  in  an  encrypted  mes¬ 
sage.  Moreover,  all  messages  are  fresh.  Thus,  some 
postulates  -  especially  those  on  freshness  and  recog- 
nizability  -  are  no  longer  needed  here  (though  they 
may  be  needed  to  verify  that  a  protocol  is  fail-stop, 
as  we  pointed  out  earlier),  and  other  postulates  can 
be  simplified.  This  advantage  can  be  seen  from  an¬ 
other  point  of  view.  The  GNY  logic  has  a  number 
of  extensions  to  BAN  so  that  most  of  the  assump¬ 
tions  in  BAN  are  handled  explicitly  in  GNY.  If  we  use 
the  GNY  logic  to  analyze  a  fail-stop  protocol,  we  no 
longer  need  constructs  such  as  “not-originated-here” 
and  “recognizability” ,  and  thus  the  complexity  of  the 
GNY  logic  can  be  greatly  reduced. 

The  definition  of  fail-stop  protocols  does  not  satisfy 
the  crucial  assumption  necessary  for  BAN-like  logics 
-  that  all  secrets  remain  secret  during  protocol  execu¬ 
tion.  Thus  we  need  phase  2  in  the  proof  methodology. 
To  validate  the  secrecy  assumption,  we  can  divide  se¬ 
crets  into  two  types.  The  first  type  of  secrets  include 
those  that  are  used  as  keys  to  encrypt  messages  but  are 
not  sent  as  message  content.  Clearly  these  keys  cannot 
be  compromised,  on  the  assumption  that  cryptosys¬ 
tems  are  strong  and  cryptanalysis  is  infeasible.  (And 
this  is  the  basis  for  requirement  2  in  Claim  2.)  The 
other  type  includes  secrets  that  are  sent  as  message 
contents,  and  it  is  with  this  type  that  our  validation 
process  deals  in  phase  2. 

2.4  Protocol  Analysis  in  Stages 

In  authentication  protocols,  it  is  common  that  a  se¬ 
cret,  a  session  key,  is  first  sent  by  the  server  to  clients, 
who  later  use  it  in  handshake  messages.  It  appears 


that  we  cannot  cast  such  protocols  as  fail  stop  be¬ 
cause,  paradoxically,  in  phase  1  we  need  to  assume 
that  encryption  keys  are  secret  while  only  phase  2  can 
we  validate  this  assumption  (about  the  session  key). 
One  way  to  overcome  this  difficulty  is  to  analyze  such 
a  protocol  in  stages.  For  example,  given  the  following 
protocol  (our  earlier  example,  with  the  design  error 
corrected,  plus  two  handshake  messages): 


1. 

S  -►  A: 

{S,A,Ts,P,  N,k,B}kas 

2. 

S  -►  B: 

{S,B,T„P,N+l,k,A}ki. 

3. 

A  ->■  B: 

{A,  B,  Ta}k 

4. 

B  ->■  A: 

{B,  A,  Tb}k 

Table  3:  Analysis  in  stages 


we  can  first  analyze  this  protocol  without  the  hand¬ 
shake  messages,  i.e. ,  the  protocol  in  Table  3  (with  data 
item  A  now  included  in  message  2)  but  including  only 
messages  1  and  2.  After  the  3  phases  of  proof  method¬ 
ology,  if  the  verdict  is  that  the  protocol  is  secure,  then 
we  have  proven  that  in  the  second  stage  of  the  full 
protocol  (in  Table  3),  i.e.,  messages  3  and  4,  the  en¬ 
cryption  keys  are  securely  shared  between  the  message 
sender  and  recipient.  Thus  we  can  continue  and  apply 
the  whole  cycle  of  methodology  to  the  full  protocol. 
Obviously,  a  more  complicated  protocol  can  be  ana¬ 
lyzed  in  more  than  two  stages.  In  the  extreme  case, 
we  can  have  step-wise  or  message- wise  verification. 

To  summarize,  one  vital  advantage  of  designing  fail- 
stop  protocols  is  that  we  can  use  the  “possession”  rules 
in  the  GNY  logic  (among  or  in  addition  to  other  mech¬ 
anisms)  to  verify  that  the  secrecy  assumption  holds  for 
a  protocol.  This  phase  adds  considerable  credibility  to 
the  claim  that  a  protocol  has  been  analyzed  to  be  se¬ 
cure  by  the  application  of  BAN-like  logics. 

2.5  Complex  Protocols 

Security  protocols  in  distributed  systems  often  nec¬ 
essarily  interact  with  each  other  directly  or  indirectly. 
For  example,  a  complex  protocol  may  use  simpler  pro¬ 
tocols  as  building  blocks,  in  which  case  an  important 
question  is  whether  we  can  reduce  the  analysis  of  the 
complex  protocol  to  that  of  the  building  blocks  in  iso¬ 
lation  [15].  Moreover,  a  protocol  is  usually  designed 
and  implemented,  and  its  security  analyzed,  indepen¬ 
dently  of  other  protocols.  Therefore,  another  crucial 
question  is  whether  the  deployment  of  one  protocol 
invalidates  the  security  conditions  and  claims  of  an¬ 
other,  possibly  in  such  a  way  that  both  protocols  need 
to  be  modified  in  order  to  coexist  securely  [11]. 

Unfortunately  being  a  fail-stop  protocol  is  not  triv¬ 
ially  composable.  To  see  this,  observe  that  any  one 
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message  protocol  is  automatically  fail-stop  regardless 
of  the  message  structure.  If  being  fail-stop  were  a 
composable  property,  then  a  simple  induction  would 
show  that  all  protocols  of  any  length  composed  of  any 
messages  from  anyone  to  anyone  are  fail-stop.  For¬ 
tunately  it  is  easy  to  define  an  extensible  fail-stop 
protocol  property  that  is  sequentially  and  parallelly 
composable  [16]. 

Definition  2  (Extensible  Fail-Stop  Protocol) 

In  a  given  protocol,  we  call  a  message  “last”  if  no  mes¬ 
sage  in  the  protocol  is  causally  after  that  message.  A 
protocol  is  extensible  fail-stop  if  adding  any  last  mes¬ 
sage  to  the  protocol  results  m  a  fail-stop  protocol. 

A  protocol  can  contain  more  than  one  “last”  mes¬ 
sage.  For  example,  the  protocol  of  Table  3  contains 
two  messages  both  of  which  are  last. 

Claim  3  The  seguential  and  parallel  composition  of 
extensible  fail-stop  protocols  is  also  extensible  fail-stop. 

When  we  compose  protocols,  assumptions  (e.g., 
those  about  the  operating  environment)  of  the  compo¬ 
nent  protocols  must  all  be  satisfied.  If  these  assump¬ 
tions  conflict  with  each  other,  then  protocol  composi¬ 
tion  does  not  make  sense  because  the  composed  pro¬ 
tocol  may  not  be  secure  or  even  feasible  to  implement. 

We  justify  Claim  3  with  two  observations.  First, 
any  one  or  more  messages  placed  causally  before  any 
message  in  a  fail-stop  protocol  will  either  be  ignored 
by  the  protocol  or  cause  it  to  halt.  Thus,  the  result  is 
still  a  fail-stop  protocol.  Second,  suppose  that  sequen¬ 
tially  composing  part  or  all  of  an  extensible  fail-stop 
protocol,  PI,  after  a  last  message  in  an  extensible  fail- 
stop  protocol,  P 2,  were  to  yield  a  protocol  that  was 
not  fail-stop.  By  definition,  this  could  not  be  due  to  a 
message  immediately  after  a  last  message  of  P 2.  And, 
if  it  were  because  of  any  later  message,  then,  by  our 
first  observation,  PI  would  not  have  been  fail-stop  as 
was  assumed. 

If  all  individual  protocols  or  building  blocks  are  ex¬ 
tensible  fail-stop,  then  the  analysis  of  an  overall  com¬ 
plex  protocol  can  indeed  be  built  on  analysis  of  the 
individual  protocols.  For  such  sequential  or  parallel 
protocol  compositions,  the  analysis  of  secrecy  (see  Sec¬ 
tion  2.2)  is  insensitive  to  the  order  of  the  interleaving 
messages.  However,  the  correctness  of  the  overall  pro¬ 
tocol  as  analyzed  by  BAN-like  logics  may  depend  on  a 
particular  interleaving  order,  in  which  case  this  global 
ordering  should  be  part  of  the  specification  of  the  over¬ 
all  protocol.4  While  many  fail-stop  protocols  are  not 

4  BAN  analysis  is  very  sensitive  to  message  ordering,  and 
Snekkenes  first  made  explicit  the  significance  of  this  requirement 
using  counter-examples  [29]. 


extensible  fail-stop,  extensible  fail-stop  protocols  are 
not  significantly  harder  to  design  than  fail-stop  proto¬ 
cols.  For  example,  any  protocol  meeting  the  require¬ 
ments  of  Claim  2  is  extensible  fail-stop. 

3  Applying  Our  Methodology 

In  this  section,  we  demonstrate  the  use  of  the  proof 
methodology  proposed  in  the  previous  section.  We 
examine  three  published  protocols,  one  being  shown 
not  to  satisfy  the  secrecy  assumption,  and  the  other 
two  being  shown  secure. 

3.1  Example  1:  the  Nessett  Protocol 

Our  first  example  is  the  Nessett  protocol  [24],  which 
proceeds  as  follows. 


1.  A  >■  B: 

2.  B  — >■  A:  {ni}uab 

Table  4:  Nessett  protocol 

In  message  1,  A  “distributes”  a  key  kab  to  be  shared 
between  A  and  B.  The  message  includes  a  nonce  na 
which  B  regards  as  fresh,5  and  is  signed  with  A’s  pri¬ 
vate  key  k'a .  Message  2  is  a  handshake  message  which 
includes  a  nonce  nb  that  A  regards  as  fresh. 

This  protocol  is  not  fail-stop  in  its  published  form. 
For  example,  if  the  first  message  were  diverted  by  an 
intruder  to  C ,  C  would  produce  his  own  nonce,  and 
encrypt  it  with  kab  (assuming  C  to  be  an  honest  func¬ 
tioning  principal  for  the  protocol).  To  make  this  pro¬ 
tocol  fail-stop,  suppose  “B”  is  added  to  the  plaintext 
signed  by  A.  Assuming  that  no  other  protocol  these 
principals  might  run  has  a  message  (or  a  piece  of  a 
message)  of  the  same  form  as  our  modified  first  mes¬ 
sage,  the  new  protocol  would  be  fail-stop.  (If  this 
assumption  cannot  be  sustained,  protocol  identifiers 
and  version  numbers  may  be  added  as  well.) 

The  implicit  secrecy  assumption  is  that  only  A  and 
B  can  obtain  key  kab.  To  check  this  assumption,  we 
assume  that  the  attacker  can  record  both  messages 
and  can  have  access  to  A’s  public  key  ka  (which  is 
usually  assumed  to  be  public  knowledge).  Now  we  can 
use  the  possession  rules  [14]  as  follows.  Here  poss(*) 
denotes  the  possession  of  formula  x. 

poss({.B,  na,  kal}^  )  AND  poss(fca) 
poss((5,  na,kab )) 

5  We  are  aware  that  a  nonce,  as  opposed  to  a  timestamp,  is 
typically  regarded  as  fresh  only  by  the  principal  who  generates 
it.  Nonetheless,  we  follow  the  original  description  [24]. 
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and  then 

poss((_B,  na,kabj) 
poss  (kab) 

In  other  words,  an  attacker  can  obtain  kab,  and  thus 
this  protocol  violates  the  secrecy  assumption.  Such  a 
proof  (of  insecurity)  means  that  the  protocol  does  not 
satisfy  an  important  assumption  in  BAN-like  logics, 
thus  the  subsequent  analysis  using  BAN  is  meaning¬ 
less.  Nevertheless,  this  protocol  did  raise  the  legiti¬ 
mate  question  of  how  to  validate  the  secrecy  assump¬ 
tion  for  any  given  protocol.  Our  concept  of  fail-stop 
protocol  aims  precisely  to  fill  in  this  gap.  Model  theo¬ 
retic  semantics  (e.g.  [2])  was  presented  as  an  approach 
to  examining  protocol  assumptions,  including  the  se¬ 
crecy  assumption  in  this  protocol  [32].  Yet  another  at¬ 
tempt  uses  a  notion  called  terminating  protocols  [29]. 
Of  these  approaches  to  analyzing  the  Nessett  protocol, 
using  the  possession  rules  of  GNY  appears  to  yield  de¬ 
sired  results  with  the  simplest  analysis. 

We  reemphasize  that  this  validation  procedure  (us¬ 
ing  the  possession  rules)  can  be  used  to  disprove  the 
security  of  a  given  protocol  (due  to  leaking  of  secrets) 
whether  the  protocol  is  fail-stop  or  not.  Thus,  the  pro¬ 
cedure  worked  on  this  protocol  and  would  have  worked 
whether  or  not  the  changes  necessary  to  make  it  fail- 
stop  had  been  made.  However,  to  be  used  as  a  crucial 
stepping  stone  in  proving  the  security  of  a  protocol, 
this  procedure  can  be  applied  only  to  fail-stop  proto¬ 
cols,  because  in  protocols  that  are  not  fail-stop,  active 
attacks  can  be  successful  so  that  secrets  can  be  leaked 
in  ways  not  detectable  by  this  procedure. 

3.2  Example  2:  the  Wide-mouthed-frog 
Protocol 

Our  second  example  is  the  wide-mouthed-frog  pro¬ 
tocol  [5].  It  proceeds  as  shown  in  Table  5. 


1.  A^S:  A,{Ta,B,kab}kas 

2.  S^B:  {Ts,A,kab}kbs 

Table  5:  Wide-mouthed-frog  protocol 

In  message  1,  A  sends  a  timestamp,  B’ s  name,  and 
a  session  key  to  an  authentication  server  S,  all  en¬ 
crypted  with  a  key  they  share.  In  message  2,  S  sends 
the  session  key  to  B  along  with  a  timestamp  of  his 
own,  and  A’ s  name. 

Like  the  Nessett  protocol,  this  protocol  is  almost, 
but  not  quite,  fail-stop  as  published.  If  an  attacker 
were  to  prepend  a  plaintext  B  to  the  second  message 
and  send  it  immediately  back  to  the  server,  the  server 
would  treat  this  as  a  first  message  in  a  new  protocol 


run.  In  the  case  of  this  protocol,  the  inclusion  of  just 
one  more  bit  within  the  encrypted  portions  to  differen¬ 
tiate  the  messages  is  sufficient  to  insure  being  fail-stop. 
The  only  further  assumption  we  need  in  this  regard  is 
that  only  in  runs  of  this  protocol  are  messages  with  the 
form  of  message  1  received  by  the  server.  (Thus  proto¬ 
col  identifiers  and  version  numbers  are  unnecessary.) 
Even  a  dishonest  principal  can  only  initiate  a  legiti¬ 
mate  key  exchange  if  this  assumption  is  true.  Again, 
if  there  is  danger  of  this  assumption  failing,  a  protocol 
identifier  and  its  version  number  can  be  added. 

It  is  easy  to  see  that  this  protocol  satisfies  the  se¬ 
crecy  assumption  since  eavesdropping  yields  no  secrets 
unless  one  possesses  the  keys  shared  between  prin¬ 
cipals  and  server.  A  BAN  analysis  of  this  protocol 
showed  that  the  protocol  is  secure  [5,  p.  26].  Our  val¬ 
idation  of  the  secrecy  assumption  puts  that  analysis 
on  a  much  stronger  footing. 

3.3  Example  3:  the  Needham-Schroeder 
Public-Key  Protocol 

Our  third  example  is  the  Needham-Schroeder 
public-key  protocol  [22],  and  it  works  as  shown  in  Ta¬ 
ble  6.  Like  the  last  two,  it  is  not  fail-stop  as  given. 
However,  we  will  not  suggest  ways  to  make  it  fail-stop; 
further  below  we  will  show  that  it  can  be  made  to  sat¬ 
isfy  another  property,  being  fail-safe,  that  justifies  the 
application  of  our  methodology. 


1. 

A  -►  S: 

A,  B 

2. 

S  -►  A: 

{kb,  B}k , 

3. 

A  ->■  B: 

{na  1  41}  ki 

4. 

B  -►  S: 

B,  A 

5. 

S  -►  B: 

{ka,  41} j./ 

6. 

B  ->■  A: 

{na ,  Tib\ka 

7. 

A  ->■  B: 

{nb}k„ 

Table  6:  Needham-Schroeder  public-key  protocol 

In  message  2,  S  signs  a  message  certifying  that  B’ s 
public  key  is  kb.  In  message  3,  A  sends  a  nonce  to  B 
encrypted  with  B’ s  public  key.  In  message  5,  S  signs 
a  message  certifying  that  A’ s  public  key  is  ka.  A  and 
B  then  complete  handshake. 

This  protocol  is  clearly  not  fail-stop;  the  first  and 
fourth  messages  could  be  sent  by  anyone  to  anyone 
at  any  time.  As  we  noted  above,  protocols  that  are 
not  fail-stop  are  subject  to  active  attacks,  in  which 
case  validating  the  secrecy  assumption  is  not  helpful. 
Nonetheless,  we  will  show  below  that  it  satisfies  an¬ 
other  weaker  property  that  makes  the  validation  pro¬ 
cedure  useful.  For  now  we  simply  assume  this  useful¬ 
ness  and  proceed  to  prove  that  the  secrecy  assumption 
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holds.  Assume  that  an  attacker  can  record  all  mes¬ 
sages.  Moreover,  assume  that  the  attacker  possesses 
all  the  public  keys,  especially  the  public  key  of  S,  ks. 
Using  the  possession  rules,  the  attacker  can  only  do 
encryption  on  the  messages.  It  is  obvious  (and  can  be 
easily  made  mechanically  decidable)  that  it  is  fruitless 
to  encrypt  messages  other  than  2  and  5,  because  fur¬ 
ther  encrypting  these  messages  (i.e. ,  messages  1,  3,  4, 
6,  and  7)  cannot  help  decryption  in  the  future.  By 
encrypting  messages  2  with  5” s  public  key,  or  in  the 
language  of  the  possession  rules,  we  have: 

poss {{kb,B}^,)  AND  poss (ks) 
poss  ((kh,B)) 

and  then 

poss  (kh,B)) 
poss  (ki,) 

The  attacker  has  learned  nothing  new  -  B’s  public 
key  is  already  public  information.  Similarly,  encrypt¬ 
ing  message  5  does  not  lead  to  new  information.  Since 
no  other  encryption  of  a  signature  or  decryption  of  an 
encrypted  message  is  possible,  the  validation  proce¬ 
dure  terminates,  and  we  are  convinced  that  the  secrecy 
assumption  holds.  Note  that  the  fact  that  such  an  ar¬ 
gument  is  possible  is  because  the  protocol  in  question 
is  (assumed  to  be)  fail-stop,  so  that  no  active  attacks 
can  be  successful  and  we  can  study  the  protocol  in  its 
fixed  form.  Even  if  we  assume  that  the  attacker  is  an 
insider,  say  A,  we  can  still  show  that  A  cannot  gain 
possession  of  B’ s  private  key.  This  protocol  has  been 
analyzed  using  the  BAN  logic  [5,  p.33]. 

4  Generalization  to  Fail-Safe  Protocols 

Many  protocols,  such  as  the  one  just  discussed,  con¬ 
tain  messages  composed  entirely  of  cleartext.  Without 
changing  this  feature  it  is  impossible  to  make  such  a 
protocol  fail-stop.  Other  protocols  may  even  have  es¬ 
sential  features  that  are  incompatible  with  being  fail- 
stop.  Fortunately,  many  protocols  that  are  not  fail- 
stop  can  apparently  be  analyzed  in  the  same  way  as 
fail-stop  protocols.  While  these  protocols  may  contain 
messages  that  will  preclude  their  being  fail-stop,  it  is 
possible  to  design  them  so  that  the  response  to  any 
such  message  is  always  safe. 

We  explain  what  it  means  for  a  message  to  be  safe 
via  an  example.  Suppose  a  principal  in  a  protocol  re¬ 
ceives  a  message  in  which  the  identifiers  of  the  sender, 
intended  recipient,  protocol  run,  freshness,  or  proto¬ 
col  message  number  are  not  clearly  given.  The  prin¬ 
cipal  may  respond  to  the  sender  with  a  test  message 


that  consists  of  his  name,  intended  recipient’s  name, 
a  timestamp,  protocol  run  number,  an  indicator  that 
this  is  a  test  response  message,  a  protocol  message 
sequence  number  of  the  message  to  which  it  is  a  re¬ 
sponse,  and  possibly  a  nonce.  This  is  all  encrypted 
with  a  shared  key  or  signed  with  his  public  key  and  en¬ 
crypted  with  that  of  the  intended  recipient  (the  prin¬ 
cipal  to  whom  he  is  responding).  The  test  message 
could  include  (in  place  of  the  timestamp)  a  nonce  he 
received  previously  from  the  intended  recipient.  As¬ 
suming  that  the  intended  recipient  of  this  test  message 
did  send  the  preceeding  message,  he  can  now  resend 
the  previous  message  using  the  correct  identifiers  (e.g., 
the  correct  nonce),  and  the  protocol  can  now  continue 
just  the  same  as  a  fail-stop  protocol. 

This  test  response  message  is  safe  in  two  ways. 
First,  it  is  safe  to  send  in  that,  even  if  it  were  prompted 
by  an  active  attacker,  it  yields  nothing  that  the  at¬ 
tacker  can  use  (that  was  not  assumed  to  be  available 
to  him  already).  Second,  it  is  safe  to  receive  and  re¬ 
spond  to  in  that  it  allows  the  protocol  to  proceed  in  a 
fail-stop  manner  -  replaying  an  old  test  response  mes¬ 
sage  can  at  most  cause  a  resend  of  the  original  mes¬ 
sage  (perhaps  with  different  and  useless  data  filled  in). 
Other  active  attacks  would  be  immediately  detectable 
and  the  protocol  effectively  halted.  We  will  call  mes¬ 
sages  that  are  safe  to  send  (in  the  sense  just  explained) 
simply  “safe” .  We  will  call  those  that  are  safe  to  re¬ 
ceive  and  respond  to  “fail-stop”  since  a  protocol  com¬ 
posed  entirely  from  such  messages  is  fail-stop  (actually 
extensible  fail-stop). 

Other  types  of  safe  messages  include  messages  con¬ 
sisting  entirely  of  cleartext  that  was  already  public  or 
not  meant  to  be  kept  secret  (such  as  nonces  that  are 
not  used  as  secrets).  Also  acceptable  are  signed  mes¬ 
sages  containing  the  cleartext  just  mentioned  provided 
that  the  signer  knows  what  he  is  signing  or  clearly 
labels  those  Helds  he  does  not  know,  e.g.,  pieces  of 
previously  received  messages.  Public  key  encryption 
of  any  message  that  one  is  willing  to  share  with  the 
corresponding  principal  is  safe.  As  with  signatures, 
anything  whose  significance  is  not  known  should  be 
labelled,  and  it  must  be  assumed  that  the  correct  key 
for  the  correct  principal  is  used. 

Therefore,  the  proof  methodology  given  above  still 
applies.  We  will  call  such  protocols  fail-safe. 

Definition  3  (Fail-Safe  Protocol)  A  protocol  is 
fail-safe  if  the  response  to  any  message  that  makes  the 
protocol  not  fail-stop  is  safe. 

As  was  mentioned  above,  the  Needham-Schroeder 
public  key  protocol  is  not  fail-stop.  We  will  now  show 
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that  it  can  be  rendered  fail-safe  with  minor  modifica¬ 
tions.  The  key  certificates  sent  by  the  server  contain 
nothing  to  indicate  that  they  have  been  sent  recently 
or  as  part  of  the  protocol  run.  Thus  an  attacker  is 
not  prevented  from  substituting  outdated  certificates, 
which  possibly  containing  outdated  keys.  When  this 
was  first  observed  [5],  it  was  suggested  that  the  certifi¬ 
cates  in  messages  2  and  5  include  timestamps.  But, 
if  timestamps  are  available,  an  online  server  is  unnec¬ 
essary  in  most  instances:  principals  can  simply  hold 
their  own  certificates,  and  the  timestamp  can  be  used 
to  determine  if  the  certificate  is  still  valid.  There  is 
another  option  that  works  even  if  adequately  synchro¬ 
nized  clocks  are  not  available  and  that  will  produce  a 
fail-safe  protocol.  Instead  of  using  timestamps,  nonces 
can  be  included  in  messages  1  and  4  and  then  returned 
in  the  certificates  of  messages  2  and  5.  We  will  now 
examine  the  Needham-Schroeder  public  key  protocol 
so  modified  and  show  that  it  is  fail-safe. 

The  server  can  be  sure  of  nothing  based  on  the 
first  message  since  it  is  composed  entirely  of  cleartext. 
Therefore,  we  need  to  verify  that  message  2  is  safe. 
The  Held  that  contains  the  nonce  must  be  labelled  as 
a  received  nonce  since  S  cannot  know  what  he  is  sign¬ 
ing  when  the  nonce  is  included  in  the  certificate.6  If 
this  is  done,  the  message  is  safe  since  it  contains  only 
publicly  available  information  and  everything  signed 
is  either  known  to  S  or  properly  labelled. 

Upon  receipt  of  message  2,  because  of  the  nonce  A 
can  tell  that  it  is  a  response  to  message  1,  and  because 
of  the  signature  A  can  tell  that  it  is  from  S.  An  ac¬ 
tive  attack  will  alter  this  message  in  a  detectable  way. 
Thus,  message  2  is  also  fail-stop,  and  A  can  safely  pro¬ 
ceed  to  send  message  3.  B  cannot  be  sure  who  sent 
message  3,  but  this  is  all  right  since  message  4  is  safe 
in  the  same  way  as  message  1.  Message  5  is  both  safe 
and  fail-stop  in  the  same  way  as  message  2.  Message 
6  is  safe  provided  that  na  is  labelled  since  it  is  an  un¬ 
familiar  number  received  in  a  message  that  was  not 
fail-stop.  Message  6  is  also  fail-stop  since  any  attack 
on  it  will  be  detectable  by  A.  We  need  not  worry 
about  message  7,  since  it  is  causally  last  and  we  are 
not  worried  about  composability. 

We  have  shown  that  the  Needham-Schroeder  public 
key  protocol  can  be  made  fail-safe  with  a  few  minor 
modifications.  This  means  that  active  attacks  do  not 
yield  messages  usable  to  the  attacker,  and  we  were 
thus  justified  in  applying  our  methodology,  i.e. ,  in  do¬ 
ing  our  secrecy  assumption  analysis  in  Section  3.3. 

6  The  label  might  not  be  necessary  if  we  can  assume  that 
nonces  are  adequately  typed  or  that  public  key  certificates  have 
a  structure  that  is  always  identifiable  in  the  system. 


(Actually  that  analysis  should  be  conducted  on  the 
modified  protocol;  however,  it  is  immediate  that  this 
analysis  is  essentially  the  same.) 

5  Formalization  Using  the  Notion  of 
Causal  Consistency 

We  can  give  a  criterion  for  protocols  that  is  equiv¬ 
alent  to  being  extensible  fail-stop  and  that  is  formally 
expressible  in  a  BAN-like  logic.  This  means  that  we 
can  rigorously,  indeed  formally,  specify  what  it  means 
for  a  given  protocol  to  be  fail-stop.  Formal  specifica¬ 
tion  can  be  a  valuable  ingredient  in  protocol  analysis, 
sometimes  simply  because  of  the  way  it  forces  us  to 
represent  protocol  properties. 

This  also  means  that,  if  we  so  desire,  we  can  ex¬ 
press  all  phases  of  our  proof  methodology  in  a  single 
formal  logic,  i.e.,  SVO  [34]  with  temporal  additions 
[33]. 7  We  cannot,  however,  prove  that  this  criterion 
holds  within  the  logic,  and  must  instead  turn  to  an 
examination  of  the  accompanying  semantics.  A  proof 
within  the  semantics  may  be  no  easier  than  verifying 
that  a  protocol  is  fail-stop.  Thus,  it  remains  to  be  seen 
if  formalization  within  SVO  is  of  more  than  theoretical 
interest  with  respect  to  formal  verification. 

The  criterion  is  called,  as  was  first  described  [33], 
the  causal  consistency  criterion  (CCC)  because  in  pro¬ 
tocols  that  satisfy  it  principals  have  matching  histo¬ 
ries  of  the  protocol  (up  to  the  last  received  message). 
CCC  is  expressed  in  terms  of  a  faithfulness  assumption 
(FA)  and  a  causality  requirement  (CR).  The  faithful¬ 
ness  assumption  basically  says  that  principals  can  be 
assumed  to  follow  the  protocol,  i.e.,  they  will  not  send 
a  message  unless  they  have  sent  or  received  all  causally 
prior  messages  involving  them.  (This  corresponds  to 
clause  3  of  Claim  2  above.)  CR  says  that  any  message 
received  by  a  principal  as  part  of  a  protocol  was  pre¬ 
viously  sent  by  the  appropriate  principal.  (In  Claim  2 
this  is  what  is  achieved  by  clauses  1  and  2.)  CCC  says 
that  If  FA  holds,  then  CR  does  too.  How  to  produce  a 
formal  expression  of  CCC  from  a  protocol  description 
was  discussed  elsewhere  [33].  Here,  we  will  persist  in 
the  informal  style  of  presentation  that  we  have  used 
throughout  the  paper. 

Claim  4  A  protocol  is  extensible  fail-stop  if  and  only 
if  it  satisfies  CCC. 

7These  temporal  additions  [33]  were  made  to  AT  [2].  They 
are  equally  compatible  with  SVO,  which  has  the  added  fea¬ 
ture  of  distinguishing  the  available  messages  from  the  received 
messages  (following  GNY).  This  makes  for  a  more  natural  ex¬ 
pression  of  the  criterion,  to  be  set  out  presently. 
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A  protocol  is  fail-stop  if  and  only  if  an  active  at¬ 
tack  on  a  protocol  message  causes  any  causally  after 
messages  not  to  be  sent.  And,  this  is  true  if  and  only 
if  any  active  attack  on  a  message  is  detectable  by  the 
message  recipient.  This  is  so  if  and  only  if  the  protocol 
is  designed  so  that,  assuming  all  legitimate  principals 
follow  the  protocol  faithfully,  any  message  received  is 
exactly  as  sent  and  is  sent  by  the  appropriate  sender 
at  the  appropriate  time  -  except  possibly  causally  last 
messages.  In  extensible  fail-stop  protocols  this  excep¬ 
tion  is  removed,  which  is  to  say  that  CCC  is  satisfied. 

Note  that  Claim  4  applies  only  to  extensible  fail- 
stop  protocols.  This  is  because  of  the  last  messages, 
which  may  have  any  structure  in  an  ordinary  fail-stop 
protocol.  If  we  weaken  CCC  so  that  it  no  longer  ap¬ 
plies  to  causally  last  messages,  then  we  can  give  a 
corresponding  claim  for  fail-stop  protocols  in  general. 

6  Summary  and  Future  Work 

We  have  presented  a  methodology  to  facilitate  the 
design  and  analysis  of  secure  cryptographic  protocols. 
It  is  based  on  the  well  known  observation  that,  if  a 
program  is  well  structured,  then  its  proof  of  correct¬ 
ness  is  likely  to  be  easier  and  simpler.  Similarly,  we 
advocate  the  general  approach  of  restricting  a  protocol 
design  to  well-defined  practices  so  that  its  conforma¬ 
tion  to  certain  guidelines  ensures  that  certain  security 
properties  are  (automatically)  satisfied  and  its  proof 
of  security  is  likely  to  be  easier  and  simpler. 

In  particular,  inspired  by  the  work  on  fail-stop  pro¬ 
cessors  [27,  28],  we  have  defined  the  novel  notion  of 
a  fail-stop  protocol,  which  automatically  halts  in  re¬ 
sponse  to  any  active  attack  that  interferes  with  proto¬ 
col  execution.  By  using  this  new  notion,  we  can  reduce 
protocol  security  analysis  to  that  of  passive  attacks 
(i.e. ,  eavesdropping)  only.  Furthermore,  by  validat¬ 
ing  that  an  eavesdropper  cannot  obtain  secret  keys, 
we  can  remove  the  crucial  but  paradoxical  secrecy  as¬ 
sumption  that  is  necessary  for  applying  BAN-like  log¬ 
ics.  Such  validations  can  be  easily  performed  using 
the  possession  rules  in  the  GNY  logic,  and  they  add 
significant  credibility  to  the  (positive)  outcome  of  an 
analysis  using  BAN-like  logics.  Our  proposed  method¬ 
ology  must  validate  the  secrecy  assumption  and  also 
apply  BAN-like  logics  because  even  for  a  fail-stop  pro¬ 
tocol,  the  residue  from  its  execution  may  be  useful  to 
an  attacker  (e.g.,  as  in  the  Nessett  protocol). 

We  have  extended  the  basic  notion  to  that  of  fail¬ 
safe  protocols,  and  to  extensible  fail-stop  protocols  for 
protocol  composition.  Our  investigation  shows  that 
many  existing  protocols  are  fail-stop  or  fail-safe  in 
spirit  so  that  our  new  notions  are  not  too  limiting. 


Our  emphasis  has  been  on  protocol  designs  that 
are  easily  determined  to  be  fail-stop  or  fail-safe.  How¬ 
ever,  some  protocols,  such  as  those  to  protect  poorly- 
chosen  passwords  from  guessing  attacks  [13],  may  have 
other  requirements  that  conflict  with  some  of  the  par¬ 
ticular  fail-stop  requirements,  e.g.,  those  described  in 
Claim  2.  To  check  whether  such  protocols  are  fail- 
stop,  one  possibility  is  to  apply  tools  like  the  Inter¬ 
rogator  or  the  NRL  Protocol  Analyzer  [19]  that  can 
search  backwards  for  the  prerequisites  of  an  action 
(e.g.,  sending  a  message);  thus  one  direction  for  re¬ 
search  is  to  investigate  the  integration  of  such  methods 
within  the  methodology  set  out  herein. 

Another  research  direction  is  to  extend  the  classes 
of  fail-stop  and  fail-safe  protocols.  In  particular,  it  will 
be  fruitful  to  look  at  other  generalizations  of  the  fail- 
stop  concept,  and  at  new  concepts  within  our  general 
approach.  Finally,  it  will  be  very  interesting  to  see  if 
it  is  possible,  and  how,  to  define  a  hierarchy  of  attack 
models  so  that  a  protocol  in  one  model  can  be  easily 
converted  into  another.  This  is  analogous  to  convert¬ 
ing  protocols  between  various  fault  models  [23]. 
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